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IN THE SPECIFICATION: 

The specification as amended below with replacement paragraphs shows added text 
with underlining and deleted text with str i k e through . 

Please REPLACE paragraph [0029] as follows: 

[0029] FIG. 1 is a diagram showing a configuration example of a system according to the 
present invention. 

FIG. 2 is a diagram showing the example of arrangement of business systems. 

FIGS. 3 and 4 are exemplary input screen of definition data stored in a business process 

DB. 

FIGS. 5A, 5B, 6A and 6B show the data configuration of definition data stored in a 
business process DB. 

FIGS. 7A, 7B, 8A and 8B show exemplary event extraction definition screens. 

FIG. 9 shows an exemplary event extraction definition. 

FIG. 10 is a diagram showing a configurational example according to an event extraction 
definition. 

FIGS. 1 1 A and 1 1 B show exemplary event data. 

FIG. 12 shows the result of relation of business data. 

FIG. 13 shows an example of an SVG file for a flow expression. 

FIG. 14 shows the outline of the processing flow in an event management apparatus. 

FIG. 15 shows the relative processing flow of business data. 

FIGS. 16A, 16B, and 16C show event data, an order placement slip and an order intake 

slip. 

FIG. 17 is a schematic diagram for explaining the relative processing of business data. 
FIG. 18 shows the relation of business data. 

FIGS. 19A, 19B, 20A, 20B, 21 A and 21B 19 to 21 show examples of creation processing 
of business data (slip). 

FIGS. 22 to 27 are explanatory diagrams of the flow of event collection from a plurality of 
business systems. 
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FIGS. 28 and 29 show exemplary retrieval condition input screens of business data. 

FIG. 30 shows an exemplary display of retrieval result. 

F I GS. 31 A, 31 B, and 31C show FIG. 31 shows exemplary operation and display in the 
tracking process of a business process. 

F I GS. 32A. 32B, and 32C show FIG. 32 shows exemplary operation and display in the 
back tracking process of a business process. 

FIG. 33 shows an exemplary tracking result screen of a business process. 

FIG. 34 is a chart showing the display processing flow of Event Explorer. 

FIG. 35 is a chart showing the tracking display processing flow of a business process. 

FIG. 36 shows an exemplary alert display screen. 

FIG. 37 is a diagram showing the outline of a conventional common workflow system. 
FIG. 38 shows an example of a conventional common workflow system. 

Please REPLACE paragraph [0078] as follows: 

[0078] F I GS. 19A and 1 9 B show FIG. 19 shows an exemplary generation processing of 
business data (slip) in the case that there is no data in the event management DB 14 in the 
beginning. Supposing the event data A and event data B is queued in the event queue 12 when 
there is no data in the event management DB14 as shown in PART A F I G. 19A , the event 
relation unit 13 generates an order intake slip as shown in PART B F I G. 19B on the basis of the 
event data A and event data B. 

Please REPLACE paragraph [0080] as follows: 

[0080] F I GS. 20A and 20B show FIG. 20 shows an exemplary generation processing of 
business data (slip) in the case that the order intake slip shown in F I G. 20A PART A has been 
already generated in the event management DB 14. Supposing the event data C and event data 
D is queued in the event queue 12 when the order intake slip shown in F I G. 20A PART A has 
been already generated in the event management DB 14, the event relation unit 13 generates 
an order intake slip as shown in F I G. 20 B PART B on the basis of the event data C and event 
data D. 



Serial No. 10/823,562 

Please REPLACE paragraph [0081] as follows: 

[0081] That is, the event relation unit 13 adds "event name: inventory inquiry", "start 
time: 13:00 on August 27, 2003", and "finish time: 14:00 on August 27, 2003" in the order intake 
slip shown in F I G. 20A PART A as an event, so that a new order intake slip shown in FJGr 
208PARTB is generated. 

Please REPLACE paragraph [0082] as follows: 

[0082] F I GS. 21 A and 21 B show FIG. 21 shows exemplary generation processing of 
business data (slip) in the case that the order intake slip shown in F I G. 21 A PART A has been 
already generated in the event management DB 14. Supposing the event data E and event data 
F is queued in the event queue 12 when the order intake slip shown in FIG. 21 A PART A has 
been already generated in the event management DB 14, the event relation unit 13 generates 
an order intake slip and a delivery slip as shown in F I G. 21B PART B on the basis of the event 
data E and event data F. 

Please REPLACE paragraph [0095] as follows: 

[0095] FIGS. 31 A, 31 B and 31 C show FIG. 31 shows exemplary operation and display in 
the tracking process of a business process. Here, it is shown that an example of the case that a 
business process selected on the retrieval condition input screen is a "product process". As a 
result of retrieving the event management DB 14, for example, as shown in F I G. 31A PART A , 
"order intake: o001" which is a primary data item of an order intake slip is displayed on a display 
area of Event Explorer of the user terminal 6, and a product process is displayed in its side. "+ 
order intake: o001" displayed on the region of this Event Explorer shows that a node "order 
intake: o001" is closed, i.e., a primary data item of the order intake slip is not selected. 

Please REPLACE paragraph [0096] as follows: 

[0096] Next, "order intake: o001" is selected by using the displayed Event Explorer. 
Since the primary data item of the order intake slip is selected, as shown in F I G. 31B PART B . 
due to this selection, the node "order intake: o001" is opened, "- Order intake: o001" is 
displayed, and relative data "+ delivery: d001" to the delivery slip which is relative business data 
is displayed. Since "order intake: o001" is selected, an event of "order entry" and an event of 
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"inventory inquiry", which are relative to the order intake slip, are retrieved. As a result of this, in 
the product process displayed beside Event Explorer, for example, as shown by double- 
hatching, the activities relative to both events are changed for color and displayed. Without 
changing the color, properties such as thickness of characters and lines of the activities may be 
changed to display them. This can be easily achieved by generating data, which is used for 
illustration of a flow, beforehand by SVG (scalable vector graphic) and changing properties such 
as color and thickness of characters and lines of objects in SVG. 

Please REPLACE paragraph [0097] as follows: 

[0097] Next, when "+ delivery: d001" shown in FIG. 31B PART B is selected, a node 
"delivery: d001" is opened as shown in an area of Event Explorer in F I G. 31C PART C . and then 
"- delivery: d001" is displayed instead. Then, the event of "shipment" relative to "delivery: d001" 
selected is retrieved, and as shown by double hatching, the activities relative to the event of 
"shipment" are changed for color and displayed in a product process. 

Please REPLACE paragraph [0098] as follows 

[0098] FIG. 32 shows exemplary operation and display in a back tracking process of a 
business process. As a result of retrieving event management DB 14, for example, it is 
assumed that, as shown in FIG. 32 A PART A , "delivery: d001" which is a primary data item of a 
delivery slip is displayed on a display area of Event Explorer of the user terminal 6, and a 
product process is displayed in its side. Then, "delivery: d001" is selected on this screen of 
Event Explorer. Due to this selection, since the primary data item of the delivery slip is selected, 
as shown in FIG. 32B PART B . a node "delivery: d001" is opened, "- delivery: d001"is displayed, 
and then data "+ order intake: o001" relative to the order intake slip which is relative to business 
data is displayed. Since "delivery: d001" is selected, the event of "shipment" relative to the 
delivery slip is retrieved, and the activities relative to the event of "shipment" are changed for 
color and displayed as shown by double hatching, for example, in a product process shown in 
RG^328PARTB. 
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Please REPLACE paragraph [0099] as follows 

[0099] Next, when "+ order intake: o001 " shown in EJGt-32B PART B is selected, 

a node "order intake: o001" is opened as shown in an area of Event Explorer in F I G. 32C PART 
C, and then order intake: o001" is displayed instead. Then, the event of "order entry" and the 
event of "inventory inquiry" which are relative to "order intake: o001" selected are retrieved, and 
the activities relative to these events are changed for color and displayed, for example, as 
shown by double hatching in a product process shown in F I G. 32C PART C . Thus, the back 
tracking of going back events by turns is also possible. 

Please REPLACE paragraph [0102] as follows: 

[0102] FIG. 34 is a chart showing the display processing flow of Event Explorer. First, it 
is determined whether an unprocessed retrieval result exists (step S31). When the unprocessed 
retrieval result exists, retrieval result data is acquired (or collected) on the basis of the retrieval 
conditions inputted from the user terminal 6 (step S32). For example, in Event Explorer 
displayed on FIG. 31 A in PART A of FIG. 31 . "order intake: o001" is acquired as retrieval result 
data. 

Please REPLACE paragraph [0103] as follows: 

[0103] Next, it is determined whether the acquired retrieval result data is selected (step 
S33). When the retrieval result data is not selected, a close node is rendered (step S34), and 
then the process returns to step S31 . For example, rendering is performed as shown in "+ order 
intake: o001" shown in PART A of FIG. 31 FIG. 31 A mentioned above. 

Please REPLACE paragraph [0104] as follows: 

[0104] When the retrieval data is selected, an open node is rendered (step S35). 

For example, rendering is performed as "- order intake: o001" shown in PART B of FIG. 31ft Gr 
^8. Next, it is determined whether relative data exists (step S36), and when relative data does 
not exist, the process returns to step S31 . When the relative data exists, the relative data is 
acquired (step S37). Next, it is determined whether relative data is selected (step S 38). When 
the relative data is not selected, a close node is rendered (step S39), and then, the process 
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returns to step S36. For example, in PART B of FIG. 31 FIG. 31 B . "delivery: d001" acquired as 
the relative data of "order intake: o001" selected is rendered like "+ delivery: d001 ." 

Please REPLACE paragraph [0105] as follows: 

[0105] When the retrieval data is selected, an open node is rendered (step S40). 

For example, rendering is performed as "- delivery: d001" shown in PART C of FIG. 31 F I G. 31 C . 
When no unprocessed retrieval result is left, an edited view (the whole screen) is outputted (step 
S41), and then the processing is ended. 
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